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10 La presente invention concerne un procede et un dispositif de 

validation automatique d'un programme informatique. 

La pr§sente invention vise plus precisement un procede de 
validation automatique d'un programme informatique susceptible d'acceder a 
une memoire securisee et a une memoire non securisee, le programme utilisant 
15 au moins une fonction de chiffrement et au moins une fonction de * 
dechiffrement :\ 
^invention trouve une utilisation avantageuse, mais non limitative, " 
pour la personnalisation des cartes a microcircuits. 

De fagon connue, la personnalisation de cartes 3 microcircuit 
20 comporte des etapes de traitement sur des donnees sensibles, c'est-a-dire des 
donnees secretes que Ton souhaite proteger de toute manipulation frauduleuse. 

A titre d'exemple, un tel traitement peut consister dans les 
operations successives suivantes : 

- reception d'une donnee d'entree chiffr^e ; 

25 - dechiffrement de cette donnee chiffree avec une clef secrete, le 

resultat de cette operation de dechiffrement etant une premiere donnee 
sensible ; 

- operation logique, par exemple decalage, sur cette premiere 
donnee sensible et obtention d'une deuxieme donnee sensible ; et 

30 - chiffrement de la deuxieme donnee sensible en utilisant une 

deuxieme clef secrete. 
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On connaTt, dans le domaine de la penalisation des cartes a 
microcircuits, differentes solutions pour realiser de tels traitements preservant, 
de toute manipulation frauduleuse, les donnees sensibles obtenues en cours de 
traitement. 

Une premiere solution connue consiste a fabriquer une carte a 
microcircuit specifique, appelee "carte racine", mettant en oeuvre les differentes 

operations precitees. 

^utilisation d'une carte racine ainsi definie, permet en effet 
d'obtenir une securite absolue, ces donnees etant temporairement archivees, 
pour leur manipulation, dans une memoire interne et securisee de la carte a 

microcircuit. ■ 

Malheureusement, une carte racine ne permet de realiser que les 

traitements pour lesquels elle a ete developpee. 

Ceci implique quit est necessaire, pour mettre en oeuvre un 
nouveau traitement, de developper un masque de carte specifique adapts a ce 
traitement, ce qui necessite des couts et une duree de development non 
negligeables. 

Afin de pallier cet inconvenient, I'homme du metier de la 
personnalisation de la carte a microcircuit, utilise parfois, et de fagon connue 
20 des plates-formes securisees, adaptees a realiser differents types de traitement 

sur des donnees sensibles. 

De telles plates-formes peuvent etre constituees par des systemes 
informatiques securises ou des cartes electroniques specifiques. 

Dans ce contexte, la realisation d'un traitement particular 
comporte une premiere phase de specification et de developpement d'un 
logiciel mettant en oeuvre les differentes operations de ce traitement, et prenant 
compte des caracteristiques propres de ces plates-formes securisees. 

Au cours d'une deuxieme phase, le logiciel ainsi developpe est 
verifie manuellement par des specia.istes de ces plates-formes, qui verifient, 
30 qu'au cours de ce traitement particulier, aucune donnee sensible ne peut etre 
acc6d6e par des tiers ayant une intention frauduleuse. 



25 



Bien que plus souple d'utilisation que la carte racine, cette 
deuxieme solution necessite egalement des temps de developpement 
relativement longs, en particulier a cause de la phase de verification manuelle 
du programme par une societe specialisee. 

La presente invention permet de resoudre les problemes precites. 

La presente invention a plus particulierement pour objet un 
procede de validation automatique d'un programme informatique susceptible 
d'acceder a une memoire securisee et a une memoire non securisee, le 
programme utilisant au moins une fonction de chiffrement et au moins une 
fonction de dechiffrement ; ce procede de validation comporte une etape de 
verification au cours de laquelle on verifie : 

-que toute fonction adaptee a lire des donnees a partir de la 
memoire securisee et a produire des donnees dans la memoire non securisee 
est une fonction de chiffrement; et 

-que toute donnee produite par la fonction de dechiffrement est 
memorisee dans la memoire securisee. 

Pour la suite de ce document, on fera la distinction entre une 
"memoire securisee", c'est-a-dire une memoire accessible uniquement par un 
programme verificateur mettant en ceuvre ce procede de validation, et une 
"memoire non securisee" accessible en particulier par un utilisateur de ce 
programme verificateur, ou par d'autres programmes informatiques. 

Dans un premier mode de realisation, ces memoires securisee et 
non securisee sont des memoires physiques distinctes, correspondant a des 
composants physiques differents. 

Dans un mode de realisation prefere, les memoire securisee et 
non securisee sont des plages de registres distinctes d'un meme composant 
physique, la gestion et le controle d'acces a ces memoires etant assures de 
fagon logicielle connue de I'homme du metier, par exemple par des fonctions de 
gestion memoire de bas niveau fournies par un systeme d'exploitation securise. 

Ce procede de validation est particulierement avantageux, car 
contrairement a la carte racine et a la plate-forme securisee de Tart anterieur, il 
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permet de valider tout programme informatique utilisant des fonctions de 
cryptographie. 

II verifie en particulier, que toute fonction adaptee a lire des 
donnees depuis la memoire securisee et a produire des donnees dans la 
5 memoire non securisee est une fonction de chiffrement, ce qui permet de 
s'assurer que seules des donnees chiffrees sont accessibles par I'utilisateur de 
ce programme verificateur, ou par les autres programmes informatiques. 

Le precede de validation selon I'invention verifie egalement que 
toute donnee produite par la fonction de dechiffrement, en particulier toute 
10 donnee sensible, est memorisee dans la memoire securisee. 

Selon une premiere caracteristique, le programme informatique 
utilise egalement au moins une fonction non-cryptographique choisie parmi une 
fonction logique, une fonction de generation d'un nombre aleatoire, ou une 

fonction de controle d'integrite. 
15 L e precede de validation permet ainsi de valider tout type de 

programme utilisant des fonctions de chiffrement, de dechiffrement et aussi des 
fonctions non-cryptographiques. 

Selon une caracteristique preferee de I'invention, le programme 
informatique etant en code source, le precede comporte prealablement a 
20 I'etape de verification, une etape de compilation de ce code source en scr.pt 
binaire, I'etape de verification etant effectuee sur le script binaire ainsi genere. 

Ce mode de realisation prefere permet d'atteindre un niveau de 
securite supplementaire car i! interdit toute modification frauduleuse qui pourrait 
etre apportee sur le code source apres I'etape de verification. 

Le programme informatique est par exemple un programme de 

generation de donnees sensibles. 

Dans un mode prefere de realisation, le programme informatique 
est un programme de transformation de donnees sensibles. II recoit par 
exemple en entree des premieres donnees sensibles, par exemple des clefs 
30 securisees, effectue des operations de dechiffrement et des operations logiques 
sur ces premieres donnees sensibles et fournit, apres chiffrement, d'autres 
donnees sensibles, par exemple un code secret. 
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Selon une autre caracteristique particulierement avantageuse, 
chaque fonction utilisee par le programme informatique est associee avec au 
moins un mode operatoire definissant au moins une regie d'acces aux 
memoires securisee et non securisee, le mode operatoire etant memorise dans 
5 une table de verification utilisee au cours de l*6tape de verification. 

Ces modes operatoires sont utilises par les programmeurs lors de 
I'etape de specification et de developpement d ? un traitement particulier. 

Conformement a Tinvention, ces regies imposent notamment a 
toute fonction de dechiffrement, de memoriser les donnees produites dans une 
10 memoire securisee. 

Dans un mode prefere de realisation, le procede de validation 
comporte en outre : 

-une etape d'allocation des memoires securis6e et non securisee ; 

-une etape de chargement, dans une memoire de travail, d'un 
15 programme verificateur du script binaire, le programme verificateur etant adapte 
^ mettre en oeuvre I'etape de verification ; et 

-une etape de chargement du script binaire dans la memoire de 

travail. 

Ces differentes etapes sont mises en oeuvre par un programme 
20 principal, qui definit ainsi Tenvironnement memoire utilise par le programme 
verificateur pour la verification du script binaire. 

II trouve ainsi une utilisation dans le domaine de la 
personnalisation des cartes a microcircuits, mais aussi dans des domaines 
varies comme par exemple les transactions electroniques dans des serveurs de 
25 telecommunications. 

L'invention vise egalement un compilateur mettant en oeuvre un 
procede de validation tel que decrit succinctement ci-dessus. 

Un tel compilateur peut avantageusement etre utilise dans une 
chaTne logicielle de personnalisation de cartes a microcircuits. 
30 L'invention vise egalement un procede d'execution d'un 

programme informatique susceptible d'acceder a une memoire securisee et a 



une memoire non securisee, le programme utilisant au moins une fonction de 
chiffrement et au moins une fonction de dechiffrement. 

Preaiablement a I'execution de chaque fonction, le precede 
d'execution selon Invention met en ceuvre une etape de verification telle que 

5 brievement decrit ci-dessus. 

Selon ce precede d'execution, preaiablement a I'execution de 
chaque fonction du programme, on verifie que cette fonction preserve, 
conformement a I'etape de verification succinctement decrit ci-dessus, la 

securite des donnees sensibles. 
10 un tel precede d'execution est particulierement fiable, car il 

Interdlt, toute manipulation du script binaire, entre la verification et I'execution 
d'une fonction. 

H peut bien evidemment etre utilise pour la personnalisation de 

cartes a microcircuits. 
15 Plus generalement, il peut etre mis en ceuvre pour la 

transformation ou la generation de donnees sensibles, par exemple dans le 
domaine des telecommunications, pour la generation de clefs dans un serveur 

de telecommunications. 

Selon un autre aspect, Invention concerne un circuit electronique 
20 integre adapte a mettre en oeuvre un procede de validation ou un precede 
d'execution tels que decrits succinctement ci-dessus. 

Un tel circuit integre peut par exemple etre modelise au moyen du 
langage VHDL connu de I'homme du metier. 

II peut aussi etre mis realise sous forme d'un composant 

25 electronique programmable. 

^invention vise aussi une carte a microcircuit et un systeme 
informatique comportant un circuit electronique integre tel que decrit 

succinctement ci-dessus. 

Selon un autre aspect, invention vise un systeme Sexploitation 
30 securise mettant en ceuvre un procede de validation tel que decrit brievement 
ci-dessus. 



Un tel systeme d'exploitation peut tres avantageusement etre 
utilise dans Industrie des cartes a microcircuits, car il permet d'implanter les 
fonctions de securite au plus bas dans la couche logicielle de ces cartes a 
microcircuits, ce qui interdit quasiment tout type d'operations frauduleuses. 
5 Dans le domaine des cartes a microcircuit, un tel systeme peut 

d'exploitation permet egalement de securiser I'execution ^application chargee 
apres y compris apres la mise sur le marche de ces cartes (en anglais "post- 
insuance"). 

L'invention vise egalement une carte a microcircuit et un systeme 
10 informatique comportant un tel systeme d'exploitation. 

Correlativement, l'invention vise un dispositif de validation d'un 
programme informatique susceptible d'acceder a une memoire securisee et a 
une memoire non securisee, le programme utilisant au moins une fonction de 
chiffrement et au moins une fonction de dechiffrement. 
15 Le dispositif de. validation comporte un programme verificateur 

adapte a verifier : 

-que toute fonction adaptee a lire des donnees a partir de la 
memoire securisee et a produire des donnees dans la memoire non securisee 
est une fonction de chiffrement ; et 
20 -que toute donnee produite par la fonction de dechiffrement est 

memorisee dans la memoire securisee. 

L'invention vise aussi un systeme informatique d'exploitation 

securise comportant : 

-des moyens de compilation d'un programme informatique en 

25 script binaire ; 

-des moyens de chargement du script binaire dans une memoire 

de travail ; 

-des moyens d'allocation d'une memoire securisee et d'une 

memoire non securisee ; et 
30 - un dispositif de validation tel que decrit brievement ci-dessus. 

Les avantages et caracteristiques particulieres propres au 
compilateur, au precede d'execution, au systeme d'exploitation securise, a la 
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Lors du d6veloppement d'un tel programme informatique, le 
developpeur doit, pour chaque operation, respecter une syntaxe memorisee 
dans une table de syntaxe TS, dont un exemple est donne a la figure 1. 
Plus precisement, chaque operation comporte : 
5 - un identifiant de la fonction ; 

- une liste d'arguments ; et 

- un caractere representatif de la fin de I'operation par exemple le 

caractere 

Ainsi, la premiere operation declaree a la ligne a1, est une 
10 operation de dechiffrement, utilisant une fonction de dechiffrement DES-1 
identifiee par I'identifiant DES-1, cette fonction utilisant trois arguments : 

- INPUT, plage d ! adresses de 8 octets contenant les donn6es a 

dechiffrer ; 

- KEY, reference a une clef cryptographique, cette reference etant 
15 memorisee sous forme d'une chame de L caracteres ; et 

- OUTPUT, plage d'adresses de 8 octets a laqueile doit §tre 
m6moris6 le resultat de la fonction de dechiffrement 

Avantageusement, dans le mode de realisation decrit ci-dessus, le 
programmeur ne connaTt pas la clef cryptographique, mais seulement sa 
20 reference KEY sous forme de chame de caracteres. Ce mode de realisation 
permet d'eviter toute fraude de la part du programmeur. 

De meme la deuxieme operation declaree a la ligne a2, est une 
operation de contrdle d'integrite, utilisant une fonction de controle d'integrite 
CHECKSUM^XOR identifiee par I'identifiant CHECKSUM_XOR, cette fonction 
25 utilisant deux arguments : 

- INPUT, plage d'adresses de 8 octets contenant les donnees 
d'entr6e de la fonction Iogique doit s'operer ; et 

- OUTPUT, adresse sur 8 octets a laqueile doit etre memorise le 
r§sultat de la fonction Iogique. 

30 Enfin, la troisieme operation declaree a la ligne a3, est une 

operation de chiffrement, utilisant une fonction de chiffrement DES identifiee par 
I'identifiant DES, cette fonction utilisant trois arguments : 
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- INPUT, plage d'adresses de 8 octets contenant les donnees a 

chiffrer ; 

- KEY, reference a une clef cryptographique, cette reference etant 
memorisee sous forme d'une chaTne de L caracteres ; et 

5 - OUTPUT, plage d'adresses sur 8 octets a laquelle doit etre 

memorise le resultat de la fonction de chiffrement. 

Chaque fonction est en outre associee a un mode operatoire 
definissant au moins une regie d'acces aux memoires, les modes operatoires 
etant memorises dans une table de verification telle que representee a la figure 

10 2. 

La figure 2 represente une table de verification conforme a la 

presente invention. 

Pour chaque fonction de chiffrement, de dechiffrement et chaque 
fonction logique, la table de verification TV comporte autant de lignes que de 
1 5 modes operatoires pour cette fonction, chaque mode operatoire definissant des 
regies d'acces aux memoires securisee MS et non securis6e MNS. 

Par exemple, la fonction de chiffrement DES comporte quatre 
modes operatoires car, dans le mode de realisation decrit ici, toute fonction de 
chiffrement est autorisee a lire et ecrire dans les memoires securisee et non 
20 securisee, sans contrainte particuliere. 

En revanche, il apparaTt dans les deux dernieres lignes de la table 
de verification TV que la fonction de dechiffrement DES-1 ne comporte que 
deux modes operatoires, toute fonction de dechiffrement etant, conformement a 
la presente invention, autorisee a ne produire des donnees que dans une 

25 memoire securisee MS. 

Nous allons maintenant decrire en reference a la figure 3 un 
programme principal mettant en oeuvre un precede de validation automatique et 
un procede d'execution du programme informatique P conformement a la 
presente invention. 

30 Le procede de validation comporte une etape preaiable E300 de 

compilation du programme informatique P de I'annexe A, cette etape de 
compilation generant un script binaire EXE. 
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Le script binaire EXE resultat de cette etape de compilation va 
maintenant etre decrit en reference a I'annexe B. 

Afin de simplifier la description, les octets du scripts binaires EXE 
sont regroupes par lignes b1 a b20. 

Les deux premiers octets du script EXE (ligne b1) correspondent a 
la taille du script binaire, soit 6C en notation hexadecimale. 

L'octet suivant (ligne b2) correspond au nombre d'operations du 
programme informatique P, soit 3. 

Les octets regroupes aux lignes b3 a b8 sont les octets generes 
par la compilation de la premiere operation (ligne a1, annexe A). 

De meme, les octets regroupes aux lignes b9 a b13 sont les octets 
generes par la compilation de la deuxieme operation (ligne a2, annexe A). 

Enfin, les octets regroupes aux lignes b14 a b19 sont les octets 
generes par la compilation de la troisieme et derniere operation (ligne a3, 
annexe A). 

Dans chacun de ces groupes : 

-la premiere ligne (lignes b3, b16 et b14) est constitute par un 
octet representant le nombre d'octets, en notation hexadecimale, genere par la 
compilation de I'operation correspondante, a savoir respectivement 24, 16 et 24 
pour les fonctions DES-1, CHECKSUM_XOR et DES ; 

-la deuxieme ligne (lignes b4, b10 et b15) est constitute par un 
octet genere par la compilation de I'identifiant de la fonction correspondante, a 
savoir respectivement 22, 53 et 21 pour les fonctions DES-1, 
CHECKSUM_XOR et DES ; 

-la troisieme ligne est constitute par un octet (lignes b5, b11 et 
b16) egal au nombre d'arguments de la fonction correspondante, a savoir 
respectivement 3, 2 et 3 pour les fonctions DES-1 , CHECKSUM_XOR et DES ; 

- la quatrieme ligne (lignes b6, b12 et b17) est constitute par les 
octets generes par la compilation du premier argument de la fonction 
correspondante ; 



- la cinquieme ligne (lignes b7. M3 et M8) est constituee par les 
octets generes par la compilation dn deuxieme argument de la fonction 

correspondante ; et 

- la sixieme ligne (lignes b8 et b1 9) est constituee, le cas echeant, 
5 par les octets generes par la compilation du troisieme argument de la fonction 

correspondante. 

Dans le mode de realisation decrit ici, la compilation dun 
argument genere tout d'abord un premier octet representatif de la zone 
memoire dans laquelle Iteration de lecture ou d'ecriture s'operant sur cet 

1 0 argument doit etre realisee. 

Dans Texemple decrit ici, quatre zones memoire sont utilisees : 
-une zone d'entree non securisee, IN_BUF, representee par 

I'octet 01 (ligne b6) ; 

- une zone de sortie non securisee, OUTJ3UF, representee par 

15 I'octet 02 (ligne b1 9) ; 

- une zone securisee de calcul, PRIVATE , representee par I octet 

04 (lignes b8, b12 et b13) ; et 

- une zone securisee de memorisation de clefs, , representee par 

I'octet 05 (lignes b7 et b18). 

La compilation d'un argument genere ensuite un deuxieme octet 
representatif de la taille de ^argument. Dans I'exemple donne ici, cette faille est 
soit 8 octets quand .'argument est une adresse, soit 12 octets (0C en notation 
hexadecimale) quand .'argument est la clef KEY constituee des 12 caracteres 

"CIPHER.TEST1 ". 

La compilation d'un argument genere enfin un groupe d'octets 

representatif de la valeur de I'argument considere. 

Dans le mode de realisation decrit ici, une plage d'adresses est 
representee dans le programme P en uti.isant la notation 
ZONE/DECALAGE/LONGUEUR, ou : 

- ZONE represents le type de la zone memoire contenant cette 
plage d'adresses, ce type etant choisi parmi la zone d'entree non securisee 



20 



25 



30 



IN_BUF, la zone de sortie non securisee OUT_BUF, la zone securisee de 
calcui PRIVATE, et la zone securisee de memorisation de clefs ; 

- DECALAGE represents le decalage ("offset" en anglais) du 
debut de cette plage d'adresses par rapport au debut de la zone ; et 

- LONGUEUR la taille de la plage d'adresses. 

Selon cette notation, le second argument 
(OUTPUT=[PRIVATE/08/01]) de I'operation logique CHECKSUM_XOR (ligne 
a2, Annexe A), signifie que le resultat de cette operation logique, doit etre 
memorise dans la zone securisee de calcul PRIVATE, dans une plage 
s'etendant sur un octet, a partir du huitieme octet de cette zone. 

Dans le mode de realisation decrit ici, le script binaire se termine 
par une serie d'octets (ligne b20) correspondant a une signature 
cryptographique obtenue a partir d'au moins une partie des octets constituant 
ce script 

L'etape E300 de compilation est suivie par une etape E305 au 
cours de laquelle le programme principal recoit : 

- d'une part des donnees d'entree du programme informatique P, 
ces donnees d'entree pouvant comporter des clefs securisees ; et 

- d'autre part le script binaire EXE genere au cours de l'etape de 
compilation E300. 

Dans le mode de realisation decrit ici, les clefs securisees sont 
memorisees dans la zone securisee de memorisation des clefs. 

L'etape de reception E305 est suivie par une etape E310 au cours 
de laquelle le programme principal alloue dynamiquement une memoire 
securisee MS et une memoire non securisee MNS. 

Cette etape d'allocation est connue de I'homme du metier et peut 
etre par exemple realisee au moyen de la fonction systeme malloc( ). 

Quoi qu'il en soit, cette etape E310 d'allocation permet d'obtenir 
un premier pointeur d'adresse BUFF_MNS, ce pointeur BUFF_MNS pointant 
sur la memoire non securisee et un deuxieme pointeur d'adresse BUFF_MS, 
pointant sur la memoire securisee. 
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Dans le mode de realisation decrit ici, la memoire non securisee 
MNS ainsi allouee est subdivisee en deux zones : 

- la zone d'entree non securisee, IN_BUF ; et 

- la zone de sortie non securisee, OUT_BUF. 
La memoire securisee MS est aussi subdivisee en deux zones : 

- la zone securisee de calcul, PRIVATE ; et 

- la zone securisee de memorisation de clefs. 
Au cours de la meme etape E310, dans un mode prefere de 

realisation, on alloue egalement une memoire de travail MT reperee par le 
pointeur BUFFJBXE, cette memoire de travail comportant le script binaire EXE 

regu au cours de l'etape E305. 

L'etape E310 deallocation des memoires est suivie par une etape 

E31 5 de verification de I'integrite du script binaire. 

Cette etape E315 peut etre par exemple realisee en verifiant la 
15 signature cryptographique du script binaire EXE, telle que decrite 
precedemment ne reference a la ligne b20 de I'annexe B. 

Cette etape E31 5 optionnelle de verification de I'integrite du script 
permet de renforcer la securite du procede de validation. 

L'etape optionnelle E315 de verification de I'integrite du script est 
20 suivie par une etape E320 au cours de laquelle on obtient le nombre 
d'operations N du programme informatique P. ce nombre N etant memorise 
dans un registre du meme nom de la memoire de travail MT. 

Dans le mode de realisation decrit ici, le nombre d'operations N 
est le troisieme octet (ligne b2) du script binaire EXE. 
25 Lorsque I'etape optionnelle E315 de verification de I'integrite du 

script n'est pas implantee, I'etape E320 d'obtention du nombre d'operations est 
consecutive a l'etape E310 deallocation des memoires decrite precedemment. 

L'etape E320 d'obtention du nombre d'operations N est suivie par 
un test E325 au cours duquel on verifie si le contenu du registre N de la 

30 memoire de travail MT egale 0. 

Lorsque tel n'est pas le cas, le resultat du test E325 est negatif. 
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Ce test est alors suivi par une etape E330 au cours de laquelle on 
obtient, dans le script binaire, I'identifiant de fonction utilisee par la premiere 
operation du programme informatique P. 

Dans I'exemple de I'annexe B, I'identifiant ainsi obtenu est 22, 
5 representatif de la fonction DES-1 (ligne b4). 

Cette etape E330 est suivie par une etape E335 au cours de 
laquelle on obtient, dans le script binaire, les arguments de cette fonction. 

En pratique, l'etape E335 d'obtention des arguments comporte : 

- une premiere sous-etape au cours de laquelle on cherche dans 
1 0 la table de syntaxe TS de la figure 1 la liste et la taille de chacun des arguments 

de la fonction ; et 

- une deuxieme sous-etape au cours de laquelle on lit le nombre 
d'octets correspondant dans le script binaire. 

L'etape E335 d'obtention des arguments de la fonction est suivie 
15 par une etape E340 d'appel a une procedure de verification de la fonction 
identifiee au cours des etapes E330 et E335. 

Les principales etapes E400 a E440 de la procedure de 
verification vont maintenant etre decrites en reference a la figure 4. 

Au cours de la premiere etape E400 de la procedure de 
20 verification, on obtient, a partir de la table de verification de la figure 2, les 
regies d'acces aux memoires securisee et non securisee, ces regies etant 
definies dans le mode operatoire de la fonction identifiee a l'etape E330. 

L'etape E400 d'obtention des regies est suivie par un test E410 au 
cours duquel on verifie si ces regies d'acces sont respectees. 
25 En pratique, cette etape de verification s'effectue en verifiant : 

- que toutes les operations de lecture et d'ecriture devant etre, 
selon ces regies, effectuees dans une memoire securisee, sont effectuees dans 
la plage d'adresse pointee par le pointeur BUFFJvIS ; et 

- que toutes les operations d'ecriture et de lecture devant etre 
30 faites dans la memoire non securisee sont effectuees dans la plage d'adresse 

pointee par le pointeur BUFF_MNS. 
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Par exemple, en parcouram les lignes b14 a b19 de .'annexe B, on 

premiers octets de ,a zone securlsee de ca,ou. PRIVATE (octet 04, ,igne b17); 
6t . une operaton d'ecrUure dans * ptage constftuee par ies 10 

^• te r;err:i.wn^ 

u„e etape E440 de notion dune erreur au programme, du programme 
> .Mormatigue ^ ^ ^ ^ ^ ^ ^ ^ „ proc , dure 

-v^^.—^ ^ te te8( ^ vaiMa(ion e345 ^ ^ 

tenant ^ on *~ s, ,a procure 
5 de vacation d,cr,te prScedemment en reference . la ** 4 , = - 
par une execuflon de ropera«on (etape E420) ou par une etape de not^cat, 
d ,rreur ^ ^ ^ 

o.es.-a-d.re par retape E420 ^execution ^operation, le resuKat du test E345 est 



30 

positif. 
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Ce test est alors suivi par une etape E350 au cours de iaquelle on 
decremente le contenu du registre N d'une unite. 

L'etape E350 est suivie par le test E325 deja decrit, test au cours 
duquel on verifie si le registre N contient la valeur 0. 

Lorsque le resultat de ce test est negatif, on execute l'etape E330 
deja decrite au cours de Iaquelle on lit dans le script binaire EXE I'identifiant de 
la fonction constituant la deuxieme operation du programme informatique P. 

Les etapes E325 a E350 constituent ainsi une boucle au cours de 
Iaquelle, si le programme informatique P respecte I'ensemble des regies 
d'acces aux memoires, toutes les operations de ce programme sont validees et 
executees. 

En revanche, lorsque la procedure de verification est terminee par 
une notification d'erreur, le resultat du test E345 est negatif. 

Ce test est alors suivi par l'etape E355 decrite ci-apres. 

Lorsque toutes les operations du programme informatique P ont . 
ete validees par la boucle constitute par les etapes E325 a E350, le resultat du 
test E325 est positif. 

Dans ce cas, le test E325 est suivi par une etape E355 au cours 
de Iaquelle on transmet le contenu de zone de sortie OUT_BUF, soit a 
I'utilisateur du programme principal, soit a un autre programme informatique de 
traitement des donnees de sortie. 

L'etape E355 est suivie par une etape E360 de liberation et 
d'effacement des memoires allouees a l'etape E310. 

Cette etape E310 termine le programme principal conforme a la 
presente invention. 

La figure 5 represente de fagon schematique un systeme 
informatique comportant un dispositif de validation conforme a la presente 
invention. 

Ce systeme informatique comporte tout d'abord un compilateur 
permettant de generer, a partir d'un programme informatique P en code source, 
un script binaire EXE tel que defini precedemment. 
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Le systeme informatique comporte egalement un systeme 
Sexploitation (en anglais, Operating System) securise. Ce systeme 
Sexploitation securise comporte des moyens d'allocation d'une memoire 
securisee MS et d'une memoire non securisee MNS. 

Ces moyens d'allocation sont en pratique, dans un mode de 
realisation prefere, des fonctions logicielles connues de I'homme du metier, par 
exemple la fonction malloc( ). Cette fonction d'allocation retourne, de fagon 
connue, un pointeur d'adresse deiimitant le debut des plages d'adresse des 
memoires securisee MS et non securisee MNS. 

Dans I'exemple de la figure 5, les pointeurs d'adresse des 
memoires securisee MS et non securisee MNS sont respectivement BUFF.MS 
et BUFF_MNS. 

Dans un mode prefere de realisation, le script binaire EXE est 
contenu dans une memoire de travail MT allouee par les moyens d'allocation 
1 5 precites et reperee par le pointeur d'adresse BUFF_EXE. 

Dans le mode de realisation decrit ici, le script binaire EXE est en 
pratique charge dans la memoire de travail par des moyens de chargement du 
systeme informatique, par exemple un bus PCI. 

Dans un autre mode de realisation, le script binaire EXE est 
20 memorise dans une memoire non volatile et charge au moment de sa 
validation. 

Le systeme informatique comporte ainsi un dispositif de validation 
comportant une programme verificateur adapte a verifier la validite du script 
binaire EXE. 

25 D'une fagon generate le programme verificateur du systeme 

informatique est adapte a mettre en ceuvre le precede de validation et le 
precede d'execution decrits precedemment en reference aux figures 3 et 4. 

Plus precisement, le programme verificateur est adapte a verifier 
que toute fonction adaptee a lire des donnees a partir de la memoire securisee 

30 MS et a produire des donnees dans la memoire non securisee MNS est une 
fonction de chiffrement. 
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II est egalement adapte a verifier que toute donnee produite par 
une fonctlon de dechiffrement est memorisee dans la memoire securisee MS. 

Le programme verificateur est en particulier adapte a parcourir le 
script binaire EXE memorise dans la memoire de travail MT, a reperer les 
instructions correspondent aux identifiants et aux arguments des fonctions de 
chiffrement, de dechiffrement et logiques apres compilation. 

Cette etape de reperage s'effectue en comparant les donnees 
hexadecimales du script binaire EXE avec les informations contenues dans la 
table de syntaxe TS decrite precedemment en ref6rence a la figure 1. 

Une fois ces identifiants et arguments de fonction reperes, le 
programme verificateur du systeme informatique est adapte a verifier que les 
regies d'acces memorisees dans la table de verification TV, decrite 
precedemment en reference a la figure 2, sont respectees. 

Pour ce faire, et pour chaque operation de lecture ou d'ecriture 
dans une memoire, il repere dans le script binaire EXE I'adresse memoire a 
laquelle cette operation doit etre realisee. 

Ensuite, il determine si cette operation est prevue pour avoir lieu 
dans la memoire securisee MS ou dans la memoire non securisee MNS, ceci 
en comparant I'adresse prevue pour ^operation avec les valeurs des pointeurs 
d'adresse BUFF_MS et BUFF_MNS. 

Une fois que le type de ces memoires est identifie, le programme 
verificateur du systeme informatique verifie que I'operation d'ecriture ou de 
lecture est conforme aux regies d'acces pour le type de fonction en cours de 
traitement. 

Dans un autre mode de realisation, le procede de validation est 
implante au niveau du systeme d'exploitation securise. Un tel systeme 
d'exploitation peut avantageusement §tre utilise dans une carte a microcircuit. 
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ANNEXES 



JTS ^NPUT - PUUWO*. KEY="CIPHER.TEST1", OUTPUT - [PR.VATE/00/08, ); 

CHECKSUM XOR (INPUT = [PRIVATB0O/O8], OUTPUT = (PRIVATE/08/011) ; 
Z', OE™™™^, KEY="CIPHER.TEST1 OUTPUT = P UTBU F ,00,10, >; 



ANNEXE B 

/*b1*/ 006C 
/*b27 03 



/*b3*/ 24 

/*b47 22 

/*b57 03. 

/*b6*/ 01 

/*b77 05 

/*b87 04 



08 0000000000000008 

OC 4349504845522E5445535431 

08 0000000000000008 



/*b97 16 
/*b10*/ 53 
/*b117 02 

/*b12*/ 04 08 0000000000000008 
/*b137 04 08 0000000800000001 

/*b14*/ 24 
/*b15*/ 21 
/*b167 03 

/*b17*/ 04 08 0000000000000009 

/*b187 05 OC 4349504845522E5445535431 

/*b197 02 08 0000000000000010 



I* taille du script 7 

1* nombre d'operations7 

/* taille instructions DES -1 7 

/* identifiant instruction DES -1 7 

/* nombre d'arguments 7 

/* INPUT 7 

/* KEY 7 

r OUTPUT 7 

/* taille instructions CHECKSUM_XOR 7 
/* identifiant instruction CHECKSUM_XOR 7 
/* nombre d'arguments 7 
I* INPUT 7 
/* OUTPUT 7 

/* taille instructions DES*/ 

/* identifiant instruction DES 7 

/* nombre d'arguments 7 

I* INPUT 7 

I* KEY 7 

/* OUTPUT 7 



/*b207 1425283678895422 



/* signature cryptbgraphique 7 
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REVENDICATIONS 

1. Procede de validation automatique d'un programme 
informatique susceptible d'acceder a une memoire securisee (MS) et a une 
memoire non securisee (MNS), le programme utilisant au moins une fonction de 
chiffrement (DES) et au moins une fonction de dechiffrement (DES-1), 
caracterise en ce qu'il comporte une etape de verification (E340) au cours de 
laquelle on verifie : 

-que toute fonction adaptee a lire des donnees a partir de ladite 
memoire securisee (MS) et a produire des donnees dans ladite memoire non 
securisee (MNS) est une fonction de chiffrement ; et 

-que toute donnee produite par ladite fonction de dechiffrement 
est memorisee dans ladite memoire securisee (MS). 

2. Procede de validation selon la revendication 1 , caracterise eh 
ce que ledit programme utilise en outre au moins une fonction nori- 
cryptographique, ladite fonction non-cryptographique etant choisie parmi une 
fonction logique, une fonction de generation d'un nombre aleatoire, ou une 
fonction de contrfile d'integrite. 

3. Procede de validation selon la revendication 2, caracterise en 
ce que toute donnee produite par ladite fonction non-cryptographique a partir 
d'une donnee lue dans ladite memoire securisee (MS) est memorisee dans 
ladite memoire securisee (MS). 

4. Procede de validation selon Tune quelconque des 
revendications 1 a 3, caracterise en ce que, le programme informatique etant 
en code source, le procede comporte, prealablement a ladite etape de 
verification (E340), une etape de compilation (E300) dudit code source en script 
binaire (EXE), ladite etape de verification (E340) etant effectuee sur le script 
binaire (EXE) ainsi genere. 
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5. Precede de validation selon I'une quelconque des 
revendications 1 a 4, caracterise en ce que ledit programme informatique est un 
programme de generation de donnees sensibles. 

6. Precede de validation selon I'une quelconque des 
revendications 1 a 5, caracterise en ce que ledit programme informatique est un 
programme de transformation de donnees sensibles. 

7. Precede de validation selon Tune quelconque des 
revendications 1 a 6, caracterise en ce que chaque fonction utilisee par ledit 
programme informatique est associee avec au moms un mode operator 
definissant au moins une regie d'acces auxdites memoires, le mode operator 
etant memorise dans une table de verification (TV) utilisee au cours de ladrte 
etape de verification (E340). 

8. Precede de validation selon la revendication 7, caracterise en 

ce qu'il comporte en outre : 

-une etape deallocation (E310) desdites memoires securisee (MS) 

et non securisee (MNS); 

-une etape de chargement, dans une memoire de travail, d'un 
programme verificateur dudit script binaire (EXE), ledit programme verificateur 
etant adapte a mettre en ceuvre ladite etape de verification (E340) ; et 

-une etape de chargement (E305) dudit script binaire (EXE) dans 

ladite memoire de travail. 

9. Compiiateur caracterise en ce qu'il est adapte a mettre en 
ceuvre un precede de validation conforme a I'une quelconque des 
revendications 1 a 7. 

10. Precede d'execution d'un programme informatique susceptible 
d'acceder a une memoire securisee (MS) et a une memoire non securisee 
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(MNS), le programme utilisant au moins une fonction de chiffrement (DES) et 
au moins une fonction de dechiffrement (DES-1), caracterise en ce que, 
prealablement a I'execution (E420) de chaque fonction dudit programme, on 
met en oeuvre une etape de verification (E340) conforme a I'une quelconque 
des revendications 1 a 8. 

11. Utilisation du procede d'execution selon !a revendication 10 
pour la transformation ou ia generation de donnees sensibles. 

12. Utilisation du procede d'execution selon la revendication 10 
pour la personnalisation de cartes a microcircuits. 

13. Circuit electronique integre caracterise en ce qu'il est adapte a 
mettre en oeuvre un procede de validation selon I'une quelconque des 
revendications 1 a 8 ou un procede d'execution conforme a la revendication 10. 

14. Carte a microcircuit caracterisee en ce qu'elle comporte circuit 
electronique integre conforme a la revendication 13. 

15. Systeme informatique caracterise en ce qu'il comporte un 
circuit electronique integre conforme a la revendication 13. 

16. Systeme d'exploitation securise adapte a mettre en ceuvre un 
procede de validation conforme a I'une quelconque des revendications 1 a 8. 

17. Carte a microcircuit caracterisee en ce qu'elle comporte un 
systeme d'exploitation selon la revendication 16. 

18. Systeme informatique caracterise en ce qu'il comporte un 
systeme d'exploitation selon la revendication 16. 



# 




24 



0 est mSmonsee dans .adite memoire secunsee (MS). 

20 . DI sp<- de va.Kat.on se,on 

verifications a partir d'un script b,na,re (EXE) obtenu p 
15 programme informatique. 

21 syst^me into— component „n systeme dotation 

m4moire d e *ava» ^ rfaiiocatjon m6mo ., re — (MS ) et d'une 
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